相信大家都有过重写 dealloc
方法来检查某个 view controller 在消失后是否被释放的经历。这几乎是 iOS 中寻找由于引用循环造成内存泄漏最有效的方法了。基本上每次发布,都会做很多次这种事情。不得不说这件事情很无聊,并且很可能会出错。如果我们在日常的开发中, 提前的学习相关的知识, 那该多好?
下面是两个很少见的 UIViewController
的属性:
isBeingDismissed
当一个模态推送出来的 view controller 正在消失的时候, 为: true.isMovingFromParentViewController
,当一个 view controller 正在从它的父 view contrlller 中移除的时候(包括从系统的容器试图比如说 UINavigationController), 为true.
如果这两个属性有一个是 true
的话, 这个 view controller 就会自动的被释放掉。我们不知道一个 view contrller 完成内部状态的改变,并且被 ARC 释放掉需要耗费多长的时间。为了简单起见,我们假设它不会超过两秒。
1.现在看看下面的代码(文末会有OC版):
|
|
在延时操作这个闭包中,我们首先通过 [weak self]
来避免这个闭包强引用self。然后通过断言让程序在 self
不为空的时候抛出异常。只有存在循环引用的情况下这个 view controller 才不为空。
现在我们需要做的就是在 viewDidDisappear
中调用这个方法。只要是你需要检查它在消失后是不是被释放掉的 view controller 都需要添加这个方法。
|
|
如果发声了内存泄漏,我们就会得到下面的断言:
这个时候,我们只需要打开 Xcode 的 Memory Graph Debugger 找到并且解决这些循环引用。
- 另外在 twitter 上也看到了类似的解决方案。
3.使用国人写的 MLeaksFinder 在每次发生内存泄漏的时候都会弹窗。并且没有代码侵入性,只需要使用 CocosPod 导入就可以了。
4.在使用图片资源的时候,少使用 imageNamed:
方法去获取使用频次不高的图片资源。因为使用 imageNamed:
加载的图片资源会一直存在内存里面, 对内存的浪费也是巨大的。
5.上面的方法写了一个 OC 版本的:
.h:
|
|
.m:
|
|
只需要在不需要检查的方法中设置属性为 YES 就好了。